無料枠の New Relic を使って WordPress を監視してみる(設定編)

セキュリティ製品特集

#AWS Elastic Beanstalk

#WordPress

#New Relic

#監視サービス

#AWS

もきゅりん

2020.11.06

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

おはようございます、もきゅりんです。

皆さん、今日も何か監視してますか？

先日のブログの無料枠の New Relic を使って WordPress を監視してみる(設計編) では監視の設計を行いました。

本稿では、設計を踏まえて実際の設定を New Relic で行っていきます。

対象としては、New Relic 初心者の方となります。

また、アカウント登録は完了していることを前提とします。

New Relic の新しい製品体系と価格体系で記載されているように、New Relic は2020年8月に大きな製品体系と価格体系の変更を行いました。

数値上限はありますが、1ユーザであれば全機能を期間制限なく無償利用できます。(フルユーザー1人に加えて、基本的な機能を利用できる基本ユーザーの人数に制限はありません。) この機会にとりあえず使わない理由はないと個人的には思います。

New Relic One user model | New Relicのドキュメント

サインアップはこちらから可能です。

New Relic の設定

前提

WordPress (以下WP) を構築済み
New Relic のアカウント登録が完了している

本稿のWPの環境としては、外部 Amazon RDS データベースを備えた高可用性の WordPress ウェブサイトを Elastic Beanstalk にデプロイするになります。

ただし、各種エージェントをインストールして、ログを New Relic に統合するため、キーペアとログストリーミングの設定はしておきます。

Elastic Beanstalk 環境の Amazon EC2 インスタンスからのログの表示

設計編でも記載していますが、下記が構成図となります。

eb_architecture_image

(本稿では、各種 New Relic のエージェントを現稼働中のインスタンスに直接インストールしてますが、Auto Scaling 環境で利用する AMI に事前に仕込むなどの準備が必要かと思います。)

New Relic のタイムゾーン設定

タイムゾーンを設定していない場合は、設定します。User preference から設定ができます。

user_preference

それでは、設計に基づいて以下の順に実際に設定を行います。

APM
Browser
Synthetics
Infrastructure/AWSリソースとの統合
Logs
Alerts

1 APM(Application Performance Monitoring)

New Relic ONE のトップページ Add your data から、またはAPMの Add more から「PHP」を選択して、表示される指示にしたがってサーバにエージェントをインストールしていきます。

add_php

適当なアプリケーション名を付けて、この環境では Amazon Linux2 のサーバにインストールするので yum を選択しました。

add_php_install_agent

しばらくすると、 APM のトップページにデータ取得されたグラフが描画されるはずです。

apm_top

データ取得できたらまずは Apdex T を設定します。( Apdex T を算出するのに24時間のデータを参照するため、本来は、1,2日間データを取得してから設定することを推奨します。 )

Apdex T とは何か？の前に、まず Apdex の概念を知る必要があります。

Apdex がどのようなものかの詳細は、Apdex：ユーザー満足度の測定をご確認頂ければと思いますが、簡単に述べると、WEBサービス/アプリケーションの応答時間について、顧客満足度を可視化する業界標準の指標です。

Apdex は、APM と Browser とで2つあります。 APM の Apdex の対象は、サーバーサイドの応答時間で、Browser の場合は、それに加えてネットワークやDOM処理、画面描画などの時間も加えた、ユーザーが体験する時間が対象となります。

そして、 Apdex T とは WEBサービス/アプリケーションの応答時間に対する顧客の満足度を決めるための「しきい値」 です。この時間よりも短時間で完了した処理は全て Satisfied (満足)として仕分けられます。

New Relic が提示する、アプリケーションの改善を継続していくために理想的な Apdex Score は0.95であり、Apdex T の値をアプリケーション処理時間の90パーセンタイル値に設定した場合に Apdex Score が0.95と一致するようです。(より多くの改善を進めたい場合、0.92や0.90となるように調整する事も可能です。)

論拠については、Apdex T: How to Set the Right Value や【New Relic Science】データの読み方とビジネスインパクト APM ② - New Relic公式ブログをご確認下さい。

なお、下記にはご注意下さい。

Apdexスコアは1分毎に算出されます。1分当たりの処理件数（RPM）が100未満の場合はスコアが不安定となる場合があります。RPMが100未満のアプリケーションでApdexスコアを元にしたAlertを設定した場合、意図しないアラートが発報する可能性があります。

ということで、 Apdex T を上記参照URLに記載されているように、下記過去24時間におけるアプリケーション処理時間の90パーセンタイル値に設定します。

select percentile(duration, 90) from Transaction where appId=YOUR_APP_ID since 24 hours ago

ちなみに、APP_ID や ACCOUNT_ID は下記から確認できます。

ヘッダタブのMore から Insightsを押下して下記イメージのように NRQL を入力します。

nrql_apdex_t

すると、下記イメージのように結果が表示されます。この値が、Apdex T です。

apdex_t_result

この値を SETTING の Application から設定します。ついでに、アプリケーション名も変更してしまいます。

application_setting

2 Browser

次に Browser の設定をします。

Browser タブからAdd more を押下して、APM 経由で自動的に有効化されるオプションの選択したまま(デフォルト)、アプリケーション名を入力します。

browser_setting

しばらくすると、Browser にデータが表示されるはずです。

それから、 Browser の Apdex T をデフォルトの7秒から4秒に変更します。 ^*1 なお、それぞれの環境や SLO, SLA などで異なってくるかと思いますので、あくまでこの値は参考値として下さい。Browser のサイドバー SETTINGS の Application settings から Apdex T の設定を更新します。

browser_apdex_setting

3 Synthetics

Syntheticsは、以下の4つのタイプから設定を選択できます。

TYPE	動作	用途
Ping	指定されたURLのHTML要素の取得時間を測定	WEBページの死活監視 (ICMPのPingとは全く別物)
Simple Browser	指定されたURLの画面取得時間を測定	WEB表示速度の推移監視
Script Browser	Selenium による設定された動作を行い、所要時間を測定	WEBシステムの稼働確認監視
API Test	API Requestをスクリプトで記述しその応答をテストする	APIの稼働確認監視

詳細は、Syntheticsモニターのタイプ | New Relicのドキュメントをご確認下さい。

本稿では、Ping および Simple Browser を設定します。

まずは Ping から設定します。 Create monitor から作成します。

Ping, Simple Browser ではオプション機能によって、ページ内の検証文字列の設定やSSL証明書チェーンの有効性を検証することもできます。

ping_setting1

東京ロケーションを選択して5分としておきます。

ping_setting2

Ping の SETTINGS > Generalsから Apdex T を4秒にしておきます。

ping_adex

Simple Browser の設定も同様としますが、Synthetics の月内チェック利用上限 100,000に対して使用量と残量が表示されています。(Ping はノーカウントです。)

SimpleBrowser1

SimpleBrowser2

Simple Browser の SETTINGS > Generalsから Apdex T を4秒にしておきます。

詳細の設定は、モニターの追加と編集 | New Relicのドキュメントをご確認下さい。

また、外形監視については、下記ブログでも詳しく機能が記載されています。

[New Relic による End to End の外形監視 - New Relic公式ブログ](https://blog.NewRelic.co.jp/new-relic-basics/New Relic-synthetics-overview/)

4 Infrastructure/AWSリソースとの統合

Infrastructure

New Relic Infrastructure を導入する事により CPU, Memory, Network, Storage の値および、プロセス毎のリソース利用状況を確認することもできますが、すべてのプロセスデータを送信すると、 New Relic に送信されるデータの量が増える可能性があります。

インフラストラクチャエージェントの構成設定| New Relicのドキュメント

本稿では、プロセスメトリックは無効 (デフォルト) としておきます。

Infrastructure タブからホストOS の Amazon Linux2 を選択して指示通りに進めて、ホスト (Amazon Linux2 ) にエージェントにインストールします。

infra_success

これで EC2 インスタンスのメトリクス取得ができました。(AWSアカウント統合のみではメトリクス取得はできません。下記参照。)

ホストからメトリクスを確認するには、それぞれのEC2ホストにInfrastructureエージェントをインストールする必要があります。EC2アカウントを接続することで、Infrastructureはリージョン、タイプ、タグなどのEC2メタデータにアクセスできます。

host_metrics

New Relic Infrastructureで何ができるのかについては、下記ブログも参考になります。

AWSリソースとの統合

RDS のメトリクスを New Relic で一元的に監視したいので AWS アカウント統合します。

Infrastructure タブから AWS タブを押下して AWSアイコンを選択すると、設定マニュアルが表示されますので、画面の指示および AWSをNew Relic Infrastructureモニタリングに接続する | New Relicのドキュメントを参考に設定します。(どのアイコンから設定してもどのAWSリソースを対象にするか選択できます。)

なお、下記にはご注意下さい。(何でもかんでもAWSリソースを対象にしてしまうと課金いっぱいされてしまうかもよ？という話です。)

New Relic Integrationは、Amazon CloudWatch APIを使用して、モニタリングするAWSサービスからメトリックスを取得します。有効なインテグレーションの数を増やすか、AWSリソースをこれらのインテグレーションに追加するか、より多くのリージョンにインテグレーションを拡張することで、CloudWatch API呼び出し回数は増加します。これがCloudWatch APIへのリクエスト数がAWSから付与されている100万回の無料枠の上限を超える原因となり、CloudWatchの請求額を増加させる場合があります。

弊社ブログも参考になります。

New Relic Infrastructure でインテグレーションできる AWS サービスまとめ 2019.12版

任意のアカウント名と作成した IAMロールのARN を入力して、必要な AWS リソースを選択します。(EC2, EBS, RDSのみ選択しました。)

aws_integ

しばらくすると、データが表示されるかと思います。

rds_integ

5 Logs

AWS Lambda for sending CloudWatch logs | New Relic Documentation にしたがって、CloudWatch Logs からログ取得してみます。

まずは、 Application Search - AWS Serverless Application Repository に飛んで New Relic を検索して進みます。

slr1

LicenseKey を入力して、 NRLoggingEnabled を TRUE にして、IAMロールを作成することを承認することにチェックします。

slr2

Lambda Function から New Relic-log-ingestion を選択してトリガーを追加します。

logs_triger1

必要なロググループを選択してフィルタ名を入力して作成していきます。

logs_triger2

New Relic の画面から確認してみます。

logs_image

6 Alerts

New Relic のアラート条件に関するベストプラクティスの考え方は下記になります。

Best Practices For Getting Started With New Relic Alert Alert Conditions

設計編でも記載したように、 本当に必要なアラートのみ実装することを原則 とします。

設計では下記のようにしていました。

事象	アラートレベル
トップページが表示できていない	電話(強い通知)
ページロード時間の増加	電話(強い通知)
ディスク使用率 85%以上	メール/Slackなど (弱い通知)

New Relic を使ったアラートとしては下記のような設定とします。

事象	New Relic メトリクス	アラートレベル
トップページが表示できていない	Ping, Simple Browser (New Relicの死活監視)	電話 (強い通知)
ページロード時間の増加	Apdexスコア(APM/Browser) < 0.8 (5分間)	電話 (強い通知)
ディスク使用率	EC2 (85%以上の使用率), RDS (使用可能なストレージ容量1G以下)	メール/Slackなど (弱い通知)

Apdex については下記にご注意下さい。

Apdexスコアの計算に使用される式は、高スループットのアプリ向けに設計されています。アプリのスループットが100RPM未満の場合、安定したスコアを決定するのに十分なデータが収集されません。不安定な場合、Apdexアラート状態が予期しない動作をする可能性があります。

なお、 New Relic で電話通知する際には、 PagerDuty との統合や Twilio を使った Webhook の設定などが必要です。

New Relicのアラートをトリガーに電話やSMSで通知を受ける - New Relic公式ブログ

死活監視

まずは、Ping のアラートを設定します。

Syntheticモニタリングのアラート | New Relicのドキュメントを参考に進めます。Alerts & AI タブから Policies に遷移します。

まず、ポリシー名を作成してインシデントプリファレンスを設定します。インシデントプリファレンスはどのようにインシデントをグルーピングするかを決めるものです。

New Relic のアラートの用語として、「ポリシー」、「条件」、「しきい値」、「違反」、「インシデント」、「通知」があります。

ポリシーを作成する際に、条件や対象とするエンティティを組み合わせて、どのようにインシデントをグルーピングするかを決めることができます。

アラートの用語については、アラートのコンセプトとワークフロー | New Relicのドキュメントを、インシデントプリファレンスがどのようにインシデントを生成するかはアラートがいつインシデントを作成するかを指定する | New Relicのドキュメントを確認下さい。

今回はポリシー別で作成します。

ping_alert1

次に条件を作成します。

ping_alert2

しきい値を作成します。

Synthetics のアラートモニターは、3ストライクベースで動作します。つまり、モニターが 1 つのロケーションで3回試行したことでエラーが返された後に、アラートが送信されます。

アラートに通知先を関連付けます。通知先を別途 Notification channels から追加できますが、今回は簡易的に Users (自分) に対して関連付けるだけに留めます。

Simple Browser の設定も同様です。

Apdex Threshold (Browser)

次に、内部からのページロード時間の増加 (APM) と実際のユーザが体感するページロード時間の増加 (Browser) に対してアラートを設定します。

Browserのベストプラクティスガイド | New Relicのドキュメントを参考に、Apdex スコアが5分間0.8を下回った場合にアラートを出します。（Apdex スコアが0.8未満の場合は、20%以上のユーザーがウェブサイトの使用体験に「満足」していないことを意味します。）

そして、平均ページ読み込み時間が5分間で8秒を超えた場合にアラートを出します。(4秒の2倍の値としています)

Apdex Threshold (APM)

今回の WordPress 環境では、Browser と同様の設定を APM でも行うことにします。[参照] APMの Apdex スコアはそれがユーザ体験に直接影響するかどうかは構成に因るため、一概にどの構成においてもこの値をしきい値にする、と決めることはできないと考えますが、今回の WordPress の内部処理とUXは、ほぼ直結していると考えて Browser と同様の設定にしています。 [/参照]

適当なポリシー名で作成して、 Condition を設定します。今回は、対象アプリケーションのエンティティを自動的にすべて含む Application metric を選択します。各 Condition の内容については下記を確認下さい。

Create alert conditions | New Relic Documentation

Disk (Infrastructure/AWS Integration)

Alerts & AI でポリシーを作成して Infrastructure を条件に選択すると、 Infrastructure に飛びます。Storage metrics を選択してしきい値と継続時間を設定します。

同じように RDS (MySQL) の設定を行います。

RDSの場合は、使用量ではなく、残量が指標となります。

以上で、 New Relic の設定は完了とします。

最後に

よく利用されている WordPress ですが、ページ読み込みが遅い、遅くなった、といった話は度々耳にします。無料枠の New Relic の豊富な機能を利用して、その課題の特定および解消が図ることも可能ではないだろうか、自身のために監視設計を整理して振り返ってみたい、という気持ちもあってまとめてみました。

この機会に New Relic の第一歩は踏み出せたと思うので、まだまだ無数にある機能を深く触ってみたいと考えています。

以上です。

どなたかのお役に立てば幸いです。